Currently in Virtual Private cloud, Hybrid Cloud or Data center scenarios, it is common to see different Layer 2 network/sites are connected using various overlay technologies (like EVPN, VxLAN, NVO3, etc.). In these scenarios, the Overlay Edge Node (e.g. NVE, PE) uses dataplane based MAC learning and exchange the MAC reachability over BGP. The Overlay Edge node (e.g. NVE, PE) can also perform ND/ARP snooping for additional optimization and advertise the IP/MAC reachability info via BGP, so that any Edge Node (e.g. NVE, PE), upon receiving ND/ARP requests from connected L2 devices (e.g. Virtual Machines VMs) would check the local cache table for existing ND/ARP entries and reply directly to the connected L2 devices, if appropriate match is found. If there is no match found, then Edge Node would flood the request to remote Edge Nodes and wait for the reply.
FIG. 1 is a block diagram of an example network 100. In FIG. 1, a Host2 108 in L2Site2 110 has not originated any traffic. If a Host1 102 from L2Site1 104 is sending an ND/ARP request for Host2, the ND/ARP request will be flooded by network virtualization edge network element (NVE1) 106 to all remote NVE (NVE2 112 and NVE3 118 in this scenario), which in turn will flood the ND/ARP request to other connected L2 sites. The same flooding issue is observed if the MAC entry is timed out on the NVEs for any MAC. This flooding becomes a challenge in large scale data center deployments.
It is possible that an orchestrator network element, such as a controller, is made aware of the IP/MAC address of the network function virtualization (NFV)/virtual machine (VM) instances, thereby allowing controllers to exchange the IP/MAC address reachability details with adjacent NVEs. However, this still does not address the above flooding challenge, as NVEs are still required to rely on data plane (learning and/or ND/ARP snooping) and control plane (e.g. BGP advertisements/withdrawal).